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1 BACKGROUND OF THE INVENTION 

2 1 . Field of the Invention 

3 The present invention relates to a method and system for providing an unlimited 

4 number of users an independently customized broadcast. More particularly, the present 

5 invention relates to a method and system for providing a customized radio station with 

6 the same variety and control provided today in traditional radio, but customized for each 

7 individual end user independently and simultaneously. The radio station generated for 

8 each user consists of audio elements that are customized for the individual end user. 

9 2. Background Discussion 

10 Radio broadcasting provides a means for transmission of information and 

1 1 entertainment to millions of radio listeners. Traditional radio broadcasting has required a 

12 full radio broadcast station to create and assemble a single set of content (music, 

13 advertising, etc.) that is broadcast to all listeners. Current radio broadcasting attempts to 

14 tailor its content to the particular audience that the station desires to attract as listeners. 

15 For example, some radio stations dedicate programming to talk shows or a particular type 

16 of music (contemporary, country, etc.). However, current radio broadcast systems do not 

17 tailor content based on particular characteristics and desires of each individual listener. 

18 The emergence of the Internet has provided an alternate transmission media for 

19 traditional radio and other types of broadcasts. To use the Internet, broadcast signals 

20 must be digitized, packetized, and transmitted to a remote user. Because these broadcasts 

21 are digitized, the broadcast signal may be stored for later transmission. An example of a 

22 system that provides for later transmission of a broadcast signal is the Internet jukeboxes 

23 available from companies such as RealNetworks. The RealNetworks system provides 

24 access to a collection of Internet music selected to fit the individual end user. Using the 

25 RealNetworks system, a user may select and receive music or other audio content upon 

26 demand. Other systems, such as LaunchCast from Launch.com, attempt to construct a 

27 collection of Internet music appropriate for the end user by making inferences from user 

28 feedback. In these systems, content is provided using "streaming audio." In other 

29 systems, video content is provided using "streaming video." That is, the audio and video 

30 content is embedded for streaming playback within a web page. In addition, these 
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1 systems stream audio or video to the user by selecting content from the user's collection 

2 either randomly or on demand. 

3 Although known Internet radio broadcast systems have provided some 

4 convenience and advantage over traditional radio broadcasts, a number of disadvantages 

5 remain. For example, these Internet radio broadcast systems lack the ability to create a 

6 customized audio program consisting of carefully controlled variety based upon a user's 

7 preferences, demographics, and listening history. Although some web-based 

8 customizable newspapers have been developed that provide customized news based on a 

9 user's preferences and demographics, no system provides a personal radio system that 

10 allows the user to customize the radio broadcast content based on the user's preferences 

1 1 and demographics . 

12 Therefore, a need exists for a personal radio system that is customizable based on 

13 the user's preferences and demographics. More specifically, a need exists for a radio 

14 broadcast system that allows a user to select the format and content to be provided within 

15 the radio broadcast. In addition, a need exists for a personal radio system that provides a 

16 customizable radio experience over the Internet, but still provides the same experience to 

17 a listener as if listening to a traditional radio broadcast. 

18 Further, a need exists for other types of server systems that provide other types of 

19 customizable content, including video content. 

20 SUMMARY OF THE INVENTION 

21 The present invention delivers a custom broadcast, assembled on demand, for 

22 each individual user. More particularly, the present invention delivers a custom radio 

23 station, assembled on demand, for each listener. Like traditional broadcast radio, the 

24 audio experience consists of music introduced by a disk jockey (DJ), jingles, news, 

25 sports, weather, stock reports, and advertisements. However, the present invention 

26 provides for the transmission of a radio broadcast to an individual listener such that each 

27 of these audio elements is customized for the individual end user. More particularly, by 

28 maintaining a user profile that represents the preferences and particular interests of a user, 

29 and a user state that maintains the recent listening history of the user, the present system 

30 generates a uniquely tailored content stream that the user is more likely to enjoy over 

31 traditional broadcast radio. The individual's listening experience is continually refined 
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1 


and improved by modifying the user profile and updating the user state. The present 




2 


invention modifies the user profile by using information gathered directly from the user, 




3 


through collaborative filtering of other users, via data-sharing partnerships, and through 




4 


direct manipulation by radio programmers. 




5 


In an embodiment, the present invention includes a personal broadcast server 




6 


system for providing a customized broadcast to one or more users over a transmission 




7 


media. The personal broadcast server system includes: a data storage device for storing a 




8 


plurality of broadcast elements; a data management system for storing a user profile and a 




9 


user state for each of the one or more users, wherein the data management system further 




10 


stores information associated with each of the plurality of broadcast elements; a broadcast 




11 


element selector having one or more broadcast element selection functions, wherein each 




12 


broadcast element selection function is operable to select broadcast elements from the 


lh 


13 


data storage device based on a user's user profile, the user's user state, and the 


t~ : 
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14 


information associated with each of the plurality of broadcast elements; and a broadcast 




15 


server operable to receive the selected broadcast elements from the data storage device 


□ 


16 


and to provide the selected broadcast elements to the user over the transmission media. 


5 


17 


In alternate embodiments, the data storage device of the personal broadcast server 




18 


system is a file server or a database. In addition, the personal broadcast server system 


H 


19 


may be implemented as a single computing device, or alternatively, mulitple computing 


■x=r 


20 


devices. 




21 


The personal broadcast server system may also include a history of usage for each 




22 


of the users. Based on the history of usage, the present invention may prevent broadcast 


• 


23 


elements from being delivered to a user. 




24 


According to the present invention, the personal broadcast server system may be 




25 


used to provide audio or video elements to a user. In an embodiment, the audio or video 




26 


elements are streamed over the Internet to the user. The types of audio elements that may 




27 


be provided to the remote use includes music, advertising, talk by a DJ, or other audio 




78 

Zo 






29 


In yet another embodiment of the present invention, the user profiles that are 




30 


stored in the data management system include initial registration information derived 




31 


from when the user first logs in. Alternatively, the user profiles include demographic 
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information relating to each user. The user profiles may also include information related 




2 


to a user's preferred frequency of content, which may be automatically updated based on 




3 


the listening patterns of the user. 




4 


More specifically, the present invention provides a customized radio broadcast to 




5 


one or more users by providing a personal radio server system that includes a general 




6 


purpose computer having a central processing unit and memory for storing user profiles 




7 
8 


for one or more users. The central processing unit includes a program that causes the 
central processing unit to produce individual audio streams for each of the one or more 




9 


users based on the user profiles stored in memory. The individual audio streams may be 




10 


comprised of one or more audio elements, which may be stored on a filed server. 




11 


In another aspect of the present invention, a method of using a personal radio 


Q 


12 


server for transmitting customized radio content to a remote listener over a transmission 


01 


13 


media is provided. Specifically, the method comprises: storing a plurality of audio 


01 


14 


elements; dynamically generating and updating a user profile that represents the 


Z. - | ; 

: i": 


15 


preferences, demographics, and interests of the remote listener; selecting audio elements 




16 


to provide to the remote listener based on the remote listener's preferences, 


= 

i, s 


17 


demographics, and interests; and transmitting the audio elements to the remote listener 




18 


over the transmission media. In alternate embodiments, the method further includes the 


5—2 


19 


steps of maintaining a history of the audio elements provided to the remote user, and 




20 


selecting audio elements to provide to a user based on the history of audio elements 




21 


previously provided to the remote user. 




22 


In yet another embodiment, the method of providing customized radio content of 




23 


provides for selecting audio elements by receiving and storing a user's ratings of one or 




24 


more audio elements; comparing the user's ratings for the one or more audio elements to 




25 


ratings from other users; predicting the user's ratings for different audio elements based 




26 


on ratings from other users with similar ratings to the user's ratings of one or more audio 




27 


elements; and selecting audio elements based on the user's predicted ratings. 






Tn an flltprrmtf* pmhoHiment thp method for providing a customized radio 
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29 


broadcast to one or more users over a transmission media includes the steps of generating 




30 


a user profile for each user; selecting audio elements for each user based on each user's. 




31 


user profile; forming an individual audio stream for each user from the audio elements; 
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1 and transmitting the individual audio streams to the one or more users over the 

2 transmission media. Alternatively, audio elements may be selected based on the history 

3 of audio elements previously provided to the remote user. In yet another embodiment of 

4 the invention, audio elements may be selected based on a prediction of the user's ratings 

5 for different audio elements based on ratings from other users with similar ratings to 

6 related audio elements. In still another embodiment, the audio elements may be selected 

7 by the user on-demand. 

8 The customized radio broadcast server of the present invention may also work 

9 with a processor-based communications device operable to receive audio elements over a 

10 transmission media. The processor-based communications device may be a personal 

1 1 digital assistant, a wireless communications device, or a personal computer. 

□ 12 In another aspect, the present invention comprises a method for overlapping 

m 13 stored audio elements in a system for providing a customized radio broadcast. 

14 Specifically, the method includes the steps of dividing a first audio element into a 

15 plurality of audio element components; selecting one of said audio element components; 
q 16 decompressing the selected audio element component; selecting a second audio element; 
JL 17 decompressing the second audio element; mixing the decompressed audio element 
J3 18 component with the decompressed second audio element to form a mixed audio element 
CI 19 component; and compressing the mixed audio element component to form a compressed 
y 20 overlapping audio element component. The compressed overlapping audio element 

21 component may replace the selected audio component. The first audio element may be a 

22 song, while the second audio element may be a DJ introduction. 

23 In yet another embodiment, the present invention provides an audio element 

24 cache. The audio element cache is capable of caching audio elements for each user. In 

25 operation, customized radio content is provided to remote listeners in a personal radio 

26 server system by: storing a plurality of audio elements in a file server; retrieving a subset 

27 of the plurality of audio elements from the file server by predicting the content desired by 

28 a remote listener based on a user profile of the remote listener; storing the subset of the 

29 plurality of audio elements in an audio element cache; selecting audio elements to 

30 provide to a remote listener from the audio element cache; and transmitting the audio 

31 elements to the remote listener. In an embodiment, the plurality of audio elements are 
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1 stored in the audio element cache when a remote listener logs-on the personal radio 

2 server system. 

3 In still another aspect, the present invention provides a method of generating a 

4 number audio element for playing a desired number in an audio system. Specifically, the 

5 method sets forth the steps of storing a plurality of audio elements used to represent a 

6 subset of the range of numbers; defining a plurality of match types used to determine if 

7 one or more matching audio element exists in the subset of the range of numbers; 

8 defining a plurality of accuracy prefixes representative of the error associated with any 

9 rounding of the desired number to be played; setting the accuracy prefix to a value 

10 representing an exact match between the desired number and a number audio element in 

11 the stored subset of audio elements representative of the range of numbers; filtering the 

12 audio elements to determine if an exact match exists; if an exact match does not exist, 

13 rounding the desired number to a pre-determined level of precision to create an estimated 

14 desired number; setting the accuracy prefix to a value representing the error associated 

15 with any rounding of the desired number to be played; filtering the audio elements to 

16 determine if an exact match exists between the estimated desired number and any of the 

17 plurality of audio elements used to represent a subset of the range of numbers; and 

18 repeating the steps of filtering until such time as an exact match has been determined 

19 between the estimated desired number and any of the plurality of audio elements used to 

20 represent a subset of the range of numbers. Once an exact match is determined, the 

21 number audio element is transmitted to a remote user. 

22 The number audio element of the present invention may be a stock quote or an 

23 announcement of the time. Further, the number audio element may be transmitted in 

24 telephone systems, automated teller machines, or other audio system. 

25 The present invention takes advantage of a method for efficiently comparing two 

26 trinary logic representations, including the steps of creating a first data structure (referred 

27 herein as a VALUE data structure) representative of a first set of properties; creating a 

28 second data structure (referred herein as a KNOWN data structure) representative of 

29 whether the first set of properties is known; creating a third data structure (referred herein 

30 as a TARGET data structure) representative of a target set of properties; creating a fourth 

31 data structure (referred herein as a WANT data structure) representative of whether the 
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1 


target set of properties is wanted; and comparing the first, second, third, and fourth data 

^7 r r * **** 




2 


structures using bit-wise binary operations to determine whether the first set of known 




3 


properties are wanted as a target set of properties. In exemplary embodiments, the bit- 




4 


wise binary operation are performed according to the Boolean equation: (not WANT) or 




5 


(KNOWN and ((TARGET xor VALUE))). Alternatively, the bit-wise binary operation 




6 


are performed according to the Boolean equation: (not WANT) or (KNOWN and 




7 


((TARGET and VALUE) or ((not TARGET) and (not (VALUE))). These data structures 




8 


may be any size computer word, including 16 and 32-bit words. 




9 


BRIEF DESCRIPTION OF THE DRAWINGS 




10 


For a more complete understanding of the present invention and the advantages 




11 


thereof, reference is now made to the following descriptions taken in conjunction with the 




12 


accompanying drawings. In the drawings, depicted elements are not necessarily drawn to 




13 


scale and like or similar elements may be designated by the same reference numeral 


ffl 
Ifi 


14 


throughout the several views. 


rr* 
. ?^ 


15 


FIG. 1 shows a high-level block diagram of the personal radio system according 


yf 


16 


to the present invention. 




17 


FIG. 2 illustrates the architecture of a remote terminal for receiving and playing 




18 


radio broadcasts as part of the personal radio system of the present invention. 




19 


FIG. 3 illustrates a high-level block diagram of the personal radio server of the 




20 


present invention. 




21 


FIG. 4 illustrates a more detailed block diagram of the components of an 




22 


exemplary personal radio server according to the present invention. 




23 


FIG. 5 shows a more detailed block diagram of the components of the User 




24 


Profile Database (UPDP) according to an embodiment of the present invention. 




25 


FIG. 6 is a diagram of the records and components in the User History Database 




26 


according to an embodiment of the present invention. 




27 


FIG. 7 illustrates an Audio Element Database (AEDB), which contains a record 




Zo 
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29 


user. 




30 


FIG. 8 shows a more detailed block diagram of the components of an audio 




31 


server of the PRS according to the present invention. 
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1 FIG. 9 shows a more detailed block diagram of an audio server thread according 

2 to an embodiment of the present invention. 

3 FIG. 10 shows a block diagram for the Audio Element Selector (AES), its 

4 constituent Radio Program Clock (RPC) and Audio Element Selector Functions 

5 (AESF's), and their connections to the Audio Server Thread (AST) and Audio Element 

6 Database (AEDB). 

7 FIG. 11 illustrates a portion of the Audio Element Selector (AES) function that 

8 relates to the selection of a Disc Jockey Introduction for a song. 

9 FIG. 12 shows a block diagram of the Disc Jockey Song Overlap Scheme (DJSO) 

10 according to an embodiment of the present invention. 

11 FIG. 13 shows a more detailed block diagram of the Disc Jockey Song Overlap 

12 Scheme according to an embodiment of the present invention. 

13 FIG. 14 is a flow diagram of the Audio Element Selector Function (AESF), 

14 which is responsible for assembling the best audio representation of the current time from 

15 the available data. 

16 FIG. 15 illustrates a high-level block diagram of the User Customized Audio 

17 Element Cache (UAEC) of the present invention. 

18 FIGS. 16a-c show the data structures used in the determination of the content to 

19 provide a user. 

20 FIGS. 17a-c show the data structures used in the determination of the content to 

21 provide a user based on the city where the user lives. 

22 FIG. 18 is a diagram of an exemplary exclusion list data structure according to an 

23 embodiment of the present invention. 

24 FIG. 19 is a graphical representation of the use of an exclusion list data structure 

25 according to an embodiment of the present invention. 

26 While the invention is susceptible to various modifications and alternative forms, 

27 specific embodiments thereof are shown by way of example in the drawings and will 

28 herein be described in detail. It should be understood, however, that the drawings and 

29 detailed description thereto are not intended to limit the invention to the particular form 

30 disclosed, but on the contrary, the intention is to cover all modifications, equivalents, and 

31 alternatives falling within the spirit and scope of the present invention. 
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1 DESCRIPTION OF ILLUSTRATIVE EMBODIMENTS 

2 For purposes of defining the invention, the following abbreviations have been 

3 used throughout the specification: 

4 PRS Personal Radio System 

5 AS Audio Server 

6 AES Audio Element Selector 

7 FS File Server 

8 DB Database 

9 AE Audio Element 

10 AEED Audio Element Identifier (also referred to as an "ID") 

11 UP User Profile 

1 2 UPDB User Profile Database 

13 UPREG User Profile Registration Record 

14 UPDEM User Profile Demographics Record 

1 5 UPINT User Profile Interest Info Record 

1 6 UPHIST User Profile History Info Record 

1 7 UPFREQ User Profile Frequency Preference Record 

18 UPMP User Profile Music Preference Record 

19 EID Enumeration ID 

20 AST Audio Server Thread 

21 ASSMQ Audio Server Shared Message Queue 

22 ASTFQ Audio Server Thread File Queue 

23 AEDB Audio Element Data Base 

24 AESF Audio Element Selection Function 

25 UH User History Record 

26 US User State 

27 UP User Profile 

28 DJAESF Disc Jockey Audio Element Selection Function 

29 DJAE Disc Jockey Audio Element 

30 UAEC User Audio Element Cache 

31 DJSO Disc Jockey Song Overlap Scheme 
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1 UPCM User Property Compression Mechanism 

2 TRIT Trinary Property Representation 

3 XLIST Exclusion List Representation 

4 The present invention is described in relation to a personal radio server for 

5 providing customized audio content to listeners. Although the present invention is 

6 described in this context, it should be understood that the concepts disclosed herein 

7 would also apply to other forms of servers for providing broadcast content to remote 

8 users. For example, the present invention may be used to stream customized video to a 

9 remote user. 

10 FIG. 1 illustrates a high-level block diagram of the interaction between users 4a-n 

1 1 with the personal radio server 2 of an embodiment of the present invention. The main 

12 function of the personal radio server 2 is to simultaneously produce individually 

13 customized radio programs for hundreds or thousands of end users. In an embodiment, 

14 the personal radio server 2 comprises a computer program running on a host server. 

15 More particularly, an embodiment of the system comprises a C++ program running on a 

16 Linux operating system on a 500Mhz Intel Pentium III computer. A standard SQL back- 

17 end (e.g., MySQL or Oracle) is used for the persistent data storage. In an embodiment, 

18 the system is capable of supporting approximately 2,000 simultaneous users. Typically 

19 multiple such systems are clustered to create audiences of tens or hundreds of thousands. 

20 Although a particular embodiment of the personal radio server 2 is described using a C++ 

21 program with a SQL back end, it should be understood that the personal radio server 

22 software may be ported to other hardware platforms or architectures without departing 

23 from the scope of the present invention. 

24 In operation, the personal radio server 2 provides to each user 4a-n a customized 

25 radio program that may consist of the following types of content: 

26 • the user's favorite music, introduced by a user-selected DJ and in a manner of 

27 their choice 

28 • talk by a user-chosen DJ (or group of D Js) 

29 • news reports on topics that interest the particular user 

30 • sports scores and reports for only those teams selected by the user 

31 •ski reports for resorts where the user visits 
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• stock reports for companies the user has or wants to invest in 




2 


• weather in the user's local area 




3 


• traffic reports only on the routes the user takes 




4 


• advertisements for products and services that the user wants or frequently 




5 


purchases 




6 


• school closings for only those schools that the user has an affiliation 




7 


• individual and group contests 




8 


• reminders that interrupt the running program with a message 




9 


• automatic alerts which are triggered by changes such as a drop in stock prices 




10 


the user has, traffic jams on the user's particular routes, severe weather in the 




11 


user's area, etc. 




12 


• informational and instructional content about the system itself 


y! 


13 


• "virtual requests'" made by other users, but limited to requests for songs that 


Si 
yy 


14 


the current user actually likes 


LH 


15 


• audio elements, such as jingles, that know and use the user's name (e.g., "Hey 




16 


Fred, this is your radio station", or "Its time for Fred's stocks"). 


yj 


17 


It should be understood that this list of content for the customizable radio system 




18 


is merelv intended to be illustrative Other content mav be customized and delivered in 

1 ij 111 Vl Vl J 111 IV11\^ VVI W V*' 111I4U tl i4tl ▼ V/* V illvi A A WA A V iilM T V 7 V V UU i ViiilU V\i M>iAV VpAWAA T VA V\* AAA 


si 


19 


this manner without departing from the spirit and scope of the present invention. 




20 


The personal radio server 2 is attached to a network 6, which is accessible by 




21 


many users (4a-n) through remote terminals. In an embodiment, the network 6 is the 




22 


Internet, which is accessible by a significant percentage of the world population. 




23 


Alternatively, the network 6 may be a local area or limited area accessible network. 




24 


Users 4a-n connect to network 6 throueh a orocessor-based communications device 
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25 


Each nrocessor-based communications device includes software for interacting with the 
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26 


personal radio server 2 and for providing customized radio content to the user. 




27 


FIG. 2 illustrates a high-level block diagram of the architecture of a remote 




zo 
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29 


the user to access the personal radio server 2. The remote terminal 12 will generally 




30 


include a processor 12, a D/A converter 14, a speaker 16, a modem 18, and memory 20. 




31 


In an exemplary embodiment, these components are part of a personal computer system 



140239-1 




1 that includes a sound card. Alternatively, these components may be included in a 

2 personal digital assistant (PDA), a cellular telephone, or other suitable processor-based 

3 communications device. The processor 12 executes software for providing the personal 

4 radio functions to a user. The software executes in memory 20 and controls operation of 

5 processor 12. In the illustrated embodiment, the radio broadcast signal is digitally 

6 encoded and transmitted to the remote terminal 12 via modem 18 over a transmission 

7 media. The processor 12 decodes the transmission and directs all radio broadcast signals 

8 to D/A converter 14, which then transmits the radio broadcast to a speaker 16. 

9 FIG. 3 illustrates a more detailed high-level block diagram of the personal radio 

10 server system of the present invention. In an embodiment, the personal radio server 2 

11 includes a computer system, or collection of computer systems, consisting of four 

12 fundamental components: a streaming audio server (AS) 32; a highly specialized audio 

13 element selector (AES) 38; a standard SQL or hierarchical database server managing 

14 specialized data tables (DB) 36; and a file server (FS) 34. FIG. 3 further includes an 

15 indication of data flow between each of these components. Specifically, database 36, or 

16 other data management system, includes user (listener) profiles (UP), These profiles 

17 provide the audio server 32 with specific information about the type of content to 

18 broadcast to the remote listener. The audio server 32 also interfaces to the audio element 

19 selector (AES) 38 and provides a particular user's current user state (US). The AES 38 

20 uses the information provided from the user profile (UP) in database 36 and the current 

21 user state (US) to select the appropriate content to provide to the audio server. The 

22 database 36 also includes audio element records that identify the audio elements stored in 

23 the file server 34. Thus, the AES 38 selects and retrieves audio element identifiers from 

24 database 36. Then, the AES 38 provides the audio element identifier (AEID) to file 

25 server 34. The file server 34 selects the appropriate audio element (AE) that includes the 

26 desired content and provides it to the audio server 32 for transmission to the remote user. 

27 After providing the audio element to the remote user, database 36 is updated with a log 

28 entry to indicate the last audio element transmitted to the remote user 4. Each of these 

29 components is described in further detail below. 
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1 FIG. 4 illustrates a more detailed block diagram of the components of an 

2 exemplary personal radio server according to the present invention. Sections 1-4 below 

3 discuss further details relating to each component of the system. 

4 1. Streaming Audio Server (AS) 

5 The streaming audio server (AS) module 32 interfaces with the end user 4, the 

6 AES 38, DB 36, and the FS module 34. In operation, when the user 4 logs-on to the 

7 system, the software on the user's computer system, network appliance, or portable 

8 wireless-networked device initiates a connection to the AS module of the personal radio 

9 server. The user's system then requests the radio program for that end user using a 

10 standard communications protocol such as HyperText Transfer Protocol (HTTP). 

1 1 The AS module 32 then communicates with the DB module 36 to retrieve the user 

12 profile (UP) and the last user state (US) for the appropriate user from the UPDP 46. If 

13 the user has no profile {i.e., the first log-on for the user), a new UP is created and the user 

14 is issued a new user identification code and the US is set to a default initial condition. 

15 Next, the AS module 32 passes the user state and profile to AES module 38. It should be 

16 noted that in alternate embodiments, the AES 38 may request the UP directly from the 

17 DB module 36. After receiving the UP and US, the AES module 38 then uses the US and 

18 the UP to determine exactly which audio element or elements should be sent to the end 

19 user. With this information, the AS 32 requests the file(s) corresponding to the audio 

20 element(s) selected by the AES 38 from the FS 34. 

21 The AS module 32 then transmits, via streaming or other suitable method of 

22 transmission, those files to the end user's system at the appropriate bit-rate. When the 

23 files have been almost completely streamed to the end user, the AS 32 requests additional 

24 audio elements from the AES 38 and the process continues so that the stream to user 4 is 

25 uninterrupted. 

26 Although the present invention is illustrated using streaming data, it should be 

27 understood that other forms of transmitting audio content to a remote user may be used 

28 without departing from the spirit and scope of the present invention. 

29 2. Audio Element Selector (AES) 

30 The audio element selector (AES) module 38 is a highly specialized piece of 

31 software that interfaces with the AS 32 and the DB 36 modules. Internally, the AES 



140239-1 



14 



1 module 38 includes a radio program clock (RPC) 40 and a series of special audio element 

2 selection functions (AESFs) (42a-n). The RPC 40 determines what type of audio element 

3 should be sent to the user next. Under control of the RPC 40, the audio element selection 

4 functions (42a-n) select the audio elements of each type that should be sent to the end 

5 user. In an embodiment of the invention, one audio element selection function exists for 

6 each type of audio element. For example, audio elements may include 

7 • songs 

8 • introductions 

9 • news 

10 • traffic 

1 1 • weather 

12 • sports scores and game reports 

13 • stock prices, news 

14 • jingles and station identification 

15 • advertisements . 

16 • school closings 

17 • reminders 

18 • instructions 

19 • time 

20 • date 

2 1 • talk / morning show 

22 • serialized radio programs 

23 The RPC 40 is designed to choose audio element types to achieve the frequency 

24 specified in the particular user's profile. For example, the user's profile may indicate that 

25 news should be played twice an hour, sports should be played once an hour, while traffic 

26 should be provided at the end of each hour. The user may manually select these user 

27 preferences. Alternatively, the user profile may be determined by using collaborative 

28 filtering, or selected by a radio programmer. The RPC is designed to optimize the radio 

29 program to have all the content types with the appropriate frequency, and to resolve 

30 conflicts when two types of content are supposed to occur at the same time (e.g., news 
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1 and traffic report). The output of the RPC is the particular content type that should be 

2 sent to the end user next. 

3 After determining the particular content type, the AES 38 runs the AESF (42a-n) 

4 that corresponds to the content type chosen by the RPC 40. Each AESF (42a-n) uses the 

5 user's profile and past listening history to select from the DB module exactly which audio 

6 elements should be sent to the end user. The AESF insures that disallowed combinations 

7 of audio elements are not played too closely in time. For example, the AESF may be 

8 programmed to prevent repeating the same news story, playing the same song, 

9 unintentionally playing songs by the same artist, and playing an ad for a product right 

10 after an ad for a competitive product. In an embodiment, this function is provided 

1 1 through the use of "Exclusion Lists" or "XLISTs," which may include one or more 

12 exclusion lists per type of audio element. The list stores the last N elements of that type 

13 which were played (where N is selected as appropriate). Information on the exclusion list 

14 is maintained as a queue. As new elements are added, the oldest elements are removed. 

15 The AESF can then check that for each new audio element whether the selected audio 

16 element matches certain properties of past audio elements (such as the artist in the case of 

17 songs). The XLISTs differ from the UHDB in that XLISTs may be formed over different 

18 types of audio elements. For example, an XLIST may be created based on the artists 

19 played to a particular listener to prevent hearing the same artist within a predetermined 

20 number of songs. Other examples of XLISTs that may be created are for artist gender to 

21 ensure variation of artist gender from song to song. 

22 In addition to determining whether the particular combination of content type is 

23 appropriate, the AESF (42a-n) guarantees that the selected audio elements are appropriate 

24 for the end user (i.e., the user's preferred DJ, the users desired stocks, etc.). In some 

25 cases, the AESF composites multiple audio elements to generate the desired audio (i.e., 

26 the stock price "123 5/8" may actually be represented by audio elements "123" and 

27 "5/8"). Alternatively, the audio may actually be represented in an alternate format. For 

28 example, the stock price of "123 5/8" may be represented by multiple audio elements in 

29 an alternate format (for example, the audio elements may include "almost,"" 124," and 

30 " 3 /4," or even "about" and "125"). For a more complete description of the software for 
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performing this type of alternate representation format, see FIG. 14 and the 
accompanying discussion. 
3. Database (DB) 

In an embodiment, the database module 36 consists of a standard SQL or 
hierarchical database. It should be understood, however, that any data management 
system may be used without departing from the spirit and scope of the present invention. 
Within the data base, several data tables are maintained: an audio elements database 
(AEDB) 44, a user's profile database (UPDB) 46, and a user's history database (UHDB) 
48. 

The Audio Element database 44 includes one or more tables 36 that enumerate the 
"meta-properties" for each of the audio elements stored in the FS module. A "meta- 
property" is additional information that may be associated with an audio element, 
including information related to: 

• the type of audio element 

• the date the audio element was recorded 

• the expiration date for each audio element 

• the jock who recorded the audio element 

• the city referred to in the audio element (if any) 

• the user name referred to in the audio element (if any) 

• the product type being advertised in the audio element (if applicable) 

• the artist who performed the song contained in the audio element (if 
applicable) 

• the artist who wrote the song contained in the audio element (if applicable) 

• the companies referred to in the audio element (if applicable) 

• the sports teams referred in the audio element (if applicable) 

These meta-properties allow the DB 36 to select only that content which is 
appropriate for a given user, content-type, and situation. For example, some of the meta- 
properties associated with a news audio element are Type, City, and DJ. The DB module 
can be used by the AES to find all news elements that have a Type that the user is 
interested in, have a City that matches the user's home city, and have been read by the 
user's preferred DJ. 
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1 4. File Server (FS) 

2 A standard file server 34 or any dedicated network data storage device may be 

3 used for storing the audio elements. In an embodiment, files on the file server are 

4 organized for rapid retrieval by the AS when given the audio element identification 

5 retrieved from the DB 36 and chosen by the AES 38. Each audio element (AE) is stored 

6 as a compressed audio file. In an embodiment, AE's are stored in MPEG I Layer 3 

7 (commonly known as MP3) format at 20, 48, 64 and 128 kbps. Each AE may include 

8 between 0.25 seconds to 3 minutes of content depending on the type of AE. For example, 

9 a "company name" AE may be 2 seconds long, but a long news story may be a minute. 

10 Similarly, "song" AE's may be several minutes long. 

1 1 FIG. 5 shows a more detailed block diagram of the components of the User 

12 Profile Database (UPDB) 46. According to an embodiment of the present invention, for 

13 each user of the system, a Dynamically Adaptive User Profile (DAUP) (50a-n) (also 

14 referred to as the "UP") is stored within the database 46. The DAUP (50a-n) is a data 

15 structure stored in the DB 36 and used by the AES 38 to select the content that is most 

16 appropriate for the particular user based on the data stored in the user profile. This data 

17 may include, but is not necessarily limited to, data relating to a user's preferences for 

18 particular songs, types of news (e.g., international, business, etc.), or particular sports 

19 teams. Each listener's DAUP is dynamic in that the information in the database changes 

20 gradually as the user volunteers information about his or her preferences. The user can 

21 provide this information in many ways. For example, the listener may be able to 

22 dynamically rate a record or product via a web page during the transmission of a related 

23 audio element such as a song or advertisement as described in more detail below. 

24 As shown in the exemplary embodiment in FIG. 5, each entry in the DAUP 50 

25 may be divided into several components: initial registration information (UPREG) 52, 

26 information on content balance and frequency (UPFreq) 59, information on 

27 demographics (UPDEM) 56, information on interests (UPINT) 58, information on music 

28 preferences (UPMP) 60, and information on the user's profile history (54). When the user 

29 first logs in, the UPREG 52 for the DAUP is derived from a small set of initial questions. 

30 In an embodiment, the user is asked for his first name and an identification of "radio 

31 station" from a list of available formats. For example, exemplary radio formats may 
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1 include "80's rock" or "contemporary country." Both at the initial log in, and 

2 subsequently, the user may specify additional properties. For example, the user may 

3 initially be requested to identify their zip code, preferred greeting (i.e., a first name or 

4 nickname), gender, age, favorite sports teams, or stock watch list. 

5 The UPFreq 59 portion of a UP entry 50 in the UPDB 46 contains information 

6 relating to the content the user prefers in a radio broadcast. According to an embodiment 

7 of the invention, the user may control the balance between different content types by 

8 modifying the information in the database. The UPFreq 59 is a record within the DAUP 

9 50 that takes the form of a set of frequencies — one frequency for each content type. For 

10 example, the non- advertisement portion of the broadcast might be divided to provide 

11 80% music, 10% talk, and 10% news during a radio broadcast. In an embodiment, the 

12 user may not control the frequency of the advertisement portion of the broadcast. For 

13 example, an exemplary system may require the PRS to provide a user with 8 

14 advertisements per hour. 

15 In an embodiment, the user may be provided direct control over these frequencies 

16 via a web page. Alternatively, the user can be asked to select from a set of alternatives 

17 such as "mostly music, not much talk," "lot's of jokes, and stories," "serious listener, 

18 introduce and describe the songs," "extra sports news," or "more traffic and weather 

19 please." In each case, the frequency of content type may be tailored to better suit the 

20 particular listener. 

21 The UPDEM 56 portion of the database stores demographic information relating 

22 to each user. For each user, the AESF 42 that corresponds to the particular user will 

23 tailor advertisements (and some other types of content) to the particular demographics of 

24 the user. For example, the AESF may provide a commercial for luxury automobiles to a 

25 user that lives in a particular zip code, while the AESF may select a commercial for pick- 

26 up trucks to a different zip code. In an embodiment, the UPDEM 56 is a record within 

27 the DAUP 50 that takes the form of a set of binary and enumerative variables. The 

28 UPDEM 56 represents conventional demographic information about the user such as 

29 income, city, sex, age, etc. The UPDEM 56 may also include other information that is 

30 designed to help the PRS target content to a user based on the user's demographics. For 

31 example, other information that may be included in the UPDEM 56 includes categories 
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1 such as "interested-in-purchasing-computer," "car owner/' "home owner," etc. In an 

2 alternate embodiment, the user may be able to edit the information in the UPDEM 

3 through a user interface. In addition, the PRS may incorporate demographic information 

4 relating to a listener from a secondary source such as "Double-click" or "Engage." 

5 The UPHIST 54 portion of the UP stores the history of the user's states. In 

6 particular, the UPHIST may be used to retrieve the last User State (US) for a particular 

7 user when the user logs into the system. 

8 The UPINT 58 portion of the UPDB 46 allows the user to specify a list of 

9 "interests" that relate to topics that the listener would like to hear more about. In an 

10 embodiment, the UPINT 58 is a dynamic length list. The UPINT stores a list of the 

11 user's favorite sports teams, stock holdings, roads used to drive to/from work, favorite 
n 12 vacation destinations, etc. This information is used to further customize the PRS 
^ 13 broadcast. For example, the user may specify a particular interest in a few sports teams, 
frf 14 Based on this information, the sports news segment broadcast to a particular user will 

15 mention only those teams in which the user is interested. In addition, a stock report may 

Ul 16 be tailored to give the prices of the user's stock as well as news reports that bear upon the 

~ 17 particular stock. Similarly, the traffic report may only report delays on roads used by the 

^ 18 particular user. The weather report may be configured to only mention local weather, as 

D 19 well as the weather in the user's favorite vacation spot. In an embodiment, the user's 

□ 20 interest information is developed by allowing the user to select from among a checklist of 

u 21 choices. 

22 Alternatively, the user's interest information may be obtained by allowing the 

23 user to navigate through a directed acyclic graph (DAG) of interests. The DAG includes 

24 interests in a parent-child hierarchy. For example, "Yankees" may have "New York 

25 City" and "baseball" as parents, and "Steinbrenner" and "Babe Ruth" as children. A user 

26 could choose to add any of those to their interests, or could edit any of the parent or 

27 children elements. For example, by selecting "New York City," the user would be 

28 allowed to pick from its parents — (New York State, "state," "big U.S. cities"} and its 

29 children— ("Statue of liberty," "Manhattan," "NYSE," "Wall Street," etc.). 

30 The UPDB 46 may also include the user's music preferences in a separate portion 

31 of the database called the UPMP 60. The UPMP stores song ratings entered by the user. 
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1 Ratings from many users may be combined to predict ratings for new music, a process 

2 known as "collaborative filtering." Collaborative filtering involves storing a dynamic set 

3 of records associated with each user, one record for each rated song, and based on a small 

4 set of user song ratings stored in the UPMP 60, the user's rating of other songs may be 

5 predicted. In operation, the collaborative filtering process works by comparing a user's 

6 ratings to the ratings of other users in the database. If two users generally agree on many 

7 songs (i.e., the users both either dislike or like the same songs), then they are likely to 

8 agree on other songs. Thus, the PRS can predict, based on users with similar tastes in 

9 music, how a user will rate a song. Thus, based on this information, the PRS may select 

10 the content for a particular user based on this collaborative filtering process. 

11 In an embodiment of the collaborative filtering system of the present invention, 

12 the PRS system 2 will utilize data from a group of paid raters, referred to herein as 

13 "trendsetters." The trendsetters may be paid to rate many songs in their area of interest. 

14 Each trendsetter will be compared to the current user. Thus, based on the trendsetter, or 

15 trendsetters, that are most similar taste to the user, the PRS may predict the future user 

16 ratings. In an embodiment, the AESF may be configured to select songs for a particular 

17 user that are highly rated by those trendsetters that most closely represent a user's 

18 interests. 

19 To further support the collaborative filtering process and the gathering of 

20 information for each user's UPDB 46, a user may provide feedback on a song by song 

21 basis. For example, in an embodiment, the present invention increases the amount of 

22 user feedback by adding software or hardware buttons to the playing device. These 

23 buttons may include feedback information such as "Great Song!," "Pretty Good," "OK 

24 Song," "Not so hot," and "Yuk, don't play that again." Thus, the displayed software 

25 buttons allow the user to easily rate the currently playing song. 

26 In some cases the user may be unwilling to give song-by-song feedback. One 

27 format for painless feedback is the station change button of a graphical user interface of 

28 the present invention. According to an embodiment, at any point during a broadcast 

29 session, the user will be able to "change stations," either to another format, or to a similar 

30 format which is in a different state (z.e., perhaps playing a different song). The UPMP 60 
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1 stores data relating to this station change behavior and attempts to find a correlation with 

2 particular songs. 

3 Although the feedback process and the collaborative filtering process are 

4 discussed in relation to music content, it should be understood that the feedback process 

5 may be used for any type of content. For example, this feedback process may be used to 

6 select various talk shows, advertisements, or other types of audio elements. 

7 Fig. 6 shows a more detailed embodiment of the user history database (UHDP) 

8 48. In an embodiment, the UHDP 48 includes user history records for every user of the 

9 system. Each user history (60a-n) includes data for the user of the system relating to the 

10 broadcast content received by the user while logged-in to the system. In an exemplary 

11 embodiment, each set of user history records (60a-n) is organized in a hierarchical 

12 manner such that each user history includes records relating to the various "types" of 

13 content (e.g., news, music, etc.) (62a-n) provided by PRS. Within each "type" record, a 

14 record is maintained for the time the particular content was played, and an identification 

15 number ("ID") for the particular broadcast content. In this manner, the UHDP maintains 

16 a record of all audio elements played to a user, and when the audio element was played. 

17 By maintaining a list of all audio elements played, and when the elements were 

18 played, the present invention may customize future broadcast content based on past 

19 listening patterns. For example, if the user continually interrupts their audio program to 

20 jump to the traffic around 4:30 p.m., the system may automatically schedule transmission 

21 to that user of an audio element that includes traffic information at 4:30 p.m. Other 

22 examples arise from more subtle trends. For example, if the user tends to give positive 

23 feedback for mellow songs and negative feedback for active songs in the morning, and 

24 then does the reverse in the afternoon, the system may automatically vary the distribution 

25 of music accordingly. 

26 Fig. 7 illustrates another component of the DB 36 according to an embodiment of 

27 the present invention. Specifically, DB 36 includes an Audio Element Database 

28 (AEDB)44 that contains a record of all the audio elements (e.g., music, disc jockey 

29 intros, news, etc.) available to provide to a user. In an embodiment, the AEDB 44 

30 consists of a number of audio element records (70a-n) stored by the type of audio content. 

31 Each audio element type record includes a number of audio elements (72a-n) of the same 
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1 type. For example, the audio elements may include introductions for a particular song 

2 from a number of different disc jockeys. 

3 In an embodiment, each audio element (72a-n) may include an ED 74, a type 76, 

4 one or more enumeration ID's (78a-n), and a binary property list 79. The ED 74 provides 

5 a unique identification number for each audio element. The type 76 provides information 

6 relating to the type of content in the audio element. Each audio element may include one 

7 or more enumeration ED ! s (78a-n), which identify the particular demographic information 

8 to which the audio element pertains. For example, the EID may include an indication of 

9 a city to which the audio element pertains (e.g., a weather forecast for the city of Austin). 

10 Additionally, the audio element may also include many "yes/no"-type binary 

11 properties 79. These properties can be efficiently stored and compared using a special 

12 mechanism called the TRIT representation, described below. The properties 79 of the 

13 audio elements allow the DB 36 to filter out content that is not appropriate for a particular 

14 user. In addition to the "city" EED, other exemplary EED's may include the user's 

15 favorite DJ or type of news. 

16 Fig. 8 shows a more detailed block diagram of the components of an audio server 

17 32 of the PRS according to the present invention. Each user 4 interfaces to the PRS via a 

18 network 80. Once again, the network 80 may be the Internet, a WAN, or any other 

19 suitable transmission media. All communication with the running system occurs via a 

20 standard web server (WS) 82 or an alternative input/output portal. The web server 

21 negotiates user interface and input verification. Information that needs to be passed to 

22 the running AS is passed into the AS shared message queue (ASSMQ) 84. The ASSMQ 

23 listens for connections from the WS. When a connection is received, one of several 

24 messages can be passed to the ASSMQ. Such messages include "skip to next element," 

25 "song feedback," "jump to traffic," etc. The ASSMQ is then queried by the individual 

26 Audio Server Threads (ASTs) that are executing for each user. Each AST checks the 

27 queue for messages destined for the program it is generating. When a message is found, 

28 it is removed from the queue, and the instructions are followed by the AST, potentially 

29 causing modification to the course of the audio stream. For each user that has logged in 

30 to the PRS, the audio server 32 creates an audio server thread (AST) 86a-n. Each audio 

31 server thread is a separate process executing in the audio server 32. An audio server 
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1 thread is responsible for maintaining and managing each radio broadcast session for a 

2 user by communicating with the DB 36, the AES 38, and FS 34. 

3 Fig. 9 shows a more detailed block diagram of an audio server thread (AST) 86. 

4 The AST is typically composed of 4 parts: a connection 95, a User State 90, a File Queue 

5 92, and a File Buffer 93. Within each AST, a connection 95 is maintained with the end 

6 user using some transmission medium. In a preferred embodiment, this medium is wired 

7 or wireless IP; however, any other communications medium and protocol can be used. 

8 Along this connection, the uninterrupted stream of compressed audio is transmitted to the 

9 user. Each AST maintains a User State (US) 90 for the connected user. Within that state, 

10 information about the users preferences and the users listening history, are maintained. 

1 1 Upon initial connection, the user profile information for that user is gathered from the 

12 UPDB 48. Information about the user's prior listening history is gathered from the 

13 UHDB 46, and as the user receives new audio, this is incorporated into the users listening 

14 history. Upon termination of the listening session (i.e. when the user 'logs off), the 

15 listening history from that session is added to the UHDB 48. During the listening 

16 session, the AST passes the current user state to the audio element selector (AES) 38, 

17 which uses that information to select audio elements (AE's). The selected AE's are then 

18 passed back to the AST where their associated filename is queued in the File Queue. File 

19 names are then sequentially pulled off the File Queue, and the files are read in from the 

20 file system (FS) and buffered in the File Buffer 93. The File Buffer 93 is then sent across 

21 the connection 95 via a transmission medium to the end user. As the File Buffer 93 

22 empties, another filename is pulled off the File Queue. When the File Queue empties, 

23 another request is made to the AES. 

24 The AES 38 is shown in detail in Fig. 10. The AES selects an appropriate audio 

25 element by first choosing the type of audio element, then by calling the appropriate 

26 constituent Audio Element Selector Functions (AESF's) in the AES 38 to select the AE 

27 from the AEDB. First, the Radio Program Clock (RPC) within the AES uses the current 

28 User State (US) 90 and User Profile (UP) from UPDP 46 to determine the next type of 

29 AE to send to the user. The RPC bases its decision upon the current US (which contains 

30 information about how many times each type of AE has been sent to the user) and the UP 

31 (which contains user preference information about how many times per hour the user 
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1 wants each type of AE sent to them). The RPC then determines the next AE type to be 

2 sent to the user. When multiple types of AE's are appropriate, an embodiment of the 

3 invention uses a static preference ranking over AE types to determine which AE type to 

4 send. Other possibilities for resolving this situation include random selection or user set 

5 priorities. Once the RPC has chosen an AE Type, the AES executes the appropriate 

6 AESF. The AESF then uses the UP to select AE's that are appropriate for the user. The 

7 AESF then removes AE's that are excluded by the XLISTs in the US. The AESF selects 

8 one or several AE's and sends their CD's to the AST, where they are queued in the AST 

9 File Queue (ASTFQ) 92 for sending to the user as described above. 

10 FIG. 1 1 illustrates another aspect of the PRS System, and specifically, a portion 

1 1 of the Audio Element Selector (AES) function. In an embodiment, the AES is configured 

12 to provide a Disc Jockey Audio Element Selection Function (DJAESF). Specifically, 

13 FIG. 11 provides a high-level block diagram of the AESF providing a disc jockey (DJ) 

14 intro to a particular song. Although the AESF is being illustrated as a DJ intro using the 

15 DJAESF, it should be understood that other types of audio element selection functions 

16 may be created without departing from the scope of the present invention. For example, 

17 other audio element selection functions may include the selection of news introductions, 

18 song "outroductions" (which follow the song), or other suitable audio segments. 

19 As illustrated, the DJAESF is a software system that allows for the creation of a 

20 radio program in which particular music and informational content may be chosen 

21 independently of the DJ who introduces the broadcast content. In other words, a given 

22 user may control the music, news, and advertisement content through the user's profile, 

23 and independently select the DJ that the user wants to introduce the content. In this 

24 manner, the user can customize the radio broadcast by selecting the DJ. And because the 

25 DJ is an integral part of any radio program, providing the "glue" that holds the program 

26 content together by introducing songs, news segments, time, weather, and other 

27 components, the radio broadcast becomes more personal. Accordingly, the user builds a 

28 personal affinity to radio programs created by the personal radio server. 

29 The various DJ audio elements (DJAE's) are stored within AEDB 36 and FS 34. 

30 For example, DJAE's may include audio elements relating to Song Introductions, Song 

31 "Outroductions" (which follow the song), News Introductions, News Wrap-ups, Jokes, 
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and other audio segments like stories, serialized "shows" (i.e. the morning show), and 
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various other types of audio elements. Unlike conventional radio broadcasts, the DJAE 




3 


are recorded by the DJ off-line, before the construction of the personal radio broadcast. 
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In the case of song introductions, jokes, introduction of news, and some other segments, 




5 


these DJAE's may be recorded well in advance. In the case of more topical content like 
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serialized shows, the DJAE's may be recorded that morning or a few days before. Still 
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other types of content, like news stories, may be recorded just before broadcast. 






In operation, the DJAESF selects the appropriate DJAE from the DB {e.g., a 
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particular song should be preceded by an introduction of the song, the outroduction of a 
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particular song, etc.). This selection is made based upon the type and specific content of 
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the DJAE. 
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In an embodiment, information about each DJAE is represented in a uniform 
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fashion across DJ's. For example, in the case of a song introduction, the information 
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about the recording DJ, the song, and the type of introduction is stored with the DJAE. 
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15 


When selecting an introduction to precede a given song, the DJAESF is free to select a 
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DJAE that matches the song and introduction type. In this manner, the DJAESF may 
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easily replace one DJ for another throughout the broadcast. 
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The user may specify his or her DJ preference either by selecting from a fixed list 
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of available DJ's or by providing generic information about the user's DJ preferences. 
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This information is then stored in a user profile. This mechanism is more general than a 
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simpler scheme in which the user simply selects a particular DJ. For example, a classical 
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music listener may wish to hear very detailed historical descriptions of each classical 
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piece. It may not be the case that any single DJ has recorded the detailed historical 
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introductions for every classical piece that may be broadcast. However, the DJAESF 
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may use the user's profile information to select an introduction based on the "type" of DJ 
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desired rather than a specifically selected D J. 
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Once again FIG 1 1 illustrates a snecific aonlication of the DJAESF. 
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introduction to a song according to the DJAESF of the present invention. Specifically, 




30 


the DJAESF 110 includes a DJ Matcher 112 and an Introduction selector 114. The DJ 




31 


Matcher 112 is a filtering function that eliminates from contention all AE's that do not 
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1 have an appropriate DJ introduction as per current user's preferences (stored in UPDB 

2 44) and the music content that is going to be played (as stored in the AEDB 36). Once 

3 the remaining set of appropriate introductions is determined, the Introduction selector 1 14 

4 selects the DJ introduction from the AEDB 36. The introduction is then sent to the AST 

5 where it is placed on the AST File Queue (ASTFQ). The Music Ranking Generator 113 

6 in Fig. 1 1 is the portion of the system that computes a songs rating based on collaborative 

7 filtering. 

8 In an alternate embodiment, the PRS may be configured to play the Disc Jockey 

9 introduction or "outroduction" over the beginning or end of a song. FIG. 12 shows an 

10 embodiment of the Disc Jockey Song Overlap Scheme of the present invention. 

11 Specifically, the DJSO 120 comprises a computer software program for constructing, 

12 compressing, and decompressing audio files; a database for storing compressed audio 

13 files; and the software necessary to stream audio files. The motivation for DJSO is that 

14 in conventional radio broadcasts, the DJ normally "talks over" the beginning of songs by 

15 introducing the song or the artist. Alternatively, the DJ will talk over the end of a song in 

16 order to transition to new content. In an embodiment of the PRS, the DJAE's may be 

17 pre-recorded with the combination of the introduction and beginning of a song. The 

18 newly created DJAE may be stored as a new type of AE (e.g., a DJ introduced song 

19 ("DJS")). However, the total number of DJS AE's is the product of the number of DJ's 

20 and the number of Songs. Thus, the storage of the combined audio elements is only 

21 feasible when there are relatively few DJ's (or few songs). For example, if the PRS 

22 supports approximately 100 DJ's and 10,000 songs, the combination of DJ's and songs 

23 would require the storage of 1,000,000 DJS AE's that are recorded and stored separately 

24 from the Songs AE's. Once again, these AE files may be stored in a compressed format 

25 (e.g., MP3 or RealAudio). Even so, a significant amount of storage is required to store 

26 each song with an overlapping of the DJ introduction (or "outroduction"). Accordingly, a 

27 need exists for a method of combining a DJ introduction with a song audio element file 

28 without having to record a large number of DJS AE's. 

29 In an embodiment, the DJSO 120 in FIG. 12 eliminates the need to record a large 

30 number of DJS AE's. One potential solution to this problem would be to simply mix the 

31 audio of a song AE with the audio of a DJ introduction AE at the time of the broadcast. 
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1 This avoids the massive duplication of songs described above. However, given the 

2 compressed file representations of these audio elements, it is very difficult to mix 

3 (combine) the audio from the DJAE with the song AE (so that the two can be heard at the 

4 same time). Therefore, in an embodiment of the PRS of the present invention, the system 

5 may first uncompress the files, mix them as uncompressed files, and then re-compress. 

6 Although this solution eliminates the need for a large amount of storage, the re- 

7 compression step requires a great deal of computation. Typically, compression is far 

8 more expensive than decompression. Compressing a 3-minute song takes approximately 

9 3 processor minutes on an Intel Pentium HI 700 MHz processor. As a result, 

10 compressing a single audio stream requires 100% of the processing power of a single 

11 processor. Thus, given that the PRS system may handle up to 100,000 users in an 

12 embodiment of the invention, it is infeasible to dedicate 100,000 processors dedicated to 

13 this re-compression function. 

14 The present invention overcomes some of these problems by providing a DJSO 

15 120 as shown in FIGS. 12 and 13. The DJSO pre-computes the audio created by mixing 

16 the DJAE and the Song AE; the result may then be compressed and stored for rapid 

17 retrieval and immediate use later. In operation, the DJSO first divides and decompresses 

18 (at block 133) each compressed song audio file 122 into three components: a HEAD 130, 

19 a TAIL 131, and a BODY 132. The HEAD is the beginning portion of the song 134. 

20 The BODY is the middle portion, and the TAIL is the end of the song. Similarly, the 

21 song Intro 135 is decompressed at block 136 to form a song introduction. Each of these 

22 portions is compressed separately at compressor 138 so that when the HEAD, TAIL, and 

23 BODY are concatenated and streamed together, the user's audio player plays the entire 

24 song in an unaltered manner. Note that the concatenation operation is very simple, in that 

25 the AES need only play the HEAD AE, followed directly by the BODY AE, and then the 

26 TAIL AE. This operation is computationally trivial, requiring almost no processing time. 

27 As a result the concatenation of these files can be done for 1000's of simultaneous users 

28 on a single computer. 

29 Additionally, the song components are defined so that the BODY portion of the 

30 song is never overlapped ("talked over") by any Jock. In other words, the HEAD portion 

31 is longer than the longest DJ introduction AE 124 for any particular song. Similarly, the 
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1 TAIL is longer than the longest JOCK outroduction 126. In an embodiment, the length 

2 of the HEAD and TAIL for all songs can be set to be the same constant amount of time 

3 (perhaps 5 seconds). Accordingly, this limits the length of the longest overlap between 

4 DJAE and a song introduction AE, but it simplifies processing. Further, because the 

5 BODY is never overlapped by any DJAE it can be stored separately as a compressed 

6 Song BODY AE 128 independent of any introduction or outroduction. In addition to the 

7 BODY AE, for each song, one new AE is generated for each DJ introduction. This 

8 introduction AE is created by mixing the uncompressed versions of the HEAD and the DJ 

9 introduction to form a Song/Intro AE. Then, the result is compressed and concatenated 

10 with the BODY and TAIL to yield an audio stream in which the beginning of the song is 

11 mixed with the introduction while the end is unaltered. In addition, for each song, one 

12 new AE is generated for each DJ outroduction. This outroduction AE is created by 

13 mixing the uncompressed versions of the TAIL and the DJ outroduction. The result is 

14 then compressed so that it can be concatenated with the HEAD and BODY to yield an 

15 audio stream in which the end of the song is mixed with the outroduction to form a 

16 compressed Song Tail/Outroduction AE 129. In addition, the compressed song tail AE 

17 125 may be stored for users who do not want any DJ audio elements. 

18 Similar to the previously described system, the DJSO function 120 requires the 

19 duplication of AE's. An important advantage is that the BODY portion of each song 

20 need not be duplicated. The BODY portion is often more than 90% of the song, and as a 

21 result, 90% of the duplication is eliminated. Accordingly, the DJSO requires 

22 significantly less disk space to maintain the AE's. 

23 Although this aspect of the invention is illustrated using DJ audio elements and 

24 Song audio elements, it should be understood that this aspect of the invention may be 

25 used to create other types of overlapping audio elements using any of the available audio 

26 elements. For example, the audio element overlap scheme of the present invention may 

27 be used to overlap a user specific reminder over a song audio element. Alternatively, a 

28 time audio element may overlap any other audio elements to allow the time to be 

29 announced at particular intervals during a broadcast (e.g., every hour). 

30 FIG. 14 illustrates another aspect of the present invention in which the number of 

31 Audio Elements required to be stored may be reduced. Specifically, the present invention 
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1 


contemplates the automatic assembly of numbers to form stock prices, dates or times 




2 


when exactly matching audio does not exist; thereby reducing the number of audio 




3 


elements needed to be stored in order to state stock prices, or alternatively, announce 




4 


time. For example, there are approximately 1440 possible current time announcement 




5 


audio elements that could be required if every time had to be recorded separately, (i.e., 




6 


"12:00", "12:01", "12:02," etc. One simple solution which exists in the prior art today is 




7 


to record hours and minutes separately, and then composite them to produce a time z.e., 




8 


"12"+ "00", '"12"'+ "'01'", "'12'" + "'02'" etc.) This may be done with 84 recordings 




9 


(assuming the hours 1-24 are different audio than the minutes 1-24). While minimally 




10 


functional, such a system does not produce high quality audio, and does not produce 




11 


times in the way that people are used to hearing them. The current invention contains a 




12 


system for assembling time and number audio in a more natural way, while allowing for 




13 


the incorporation of exact-match audio when it is available. While presented in the 


LJl 


14 


context of the PRS, this invention has many uses beyond PRS. Specifically, this aspect 


Ln 


15 


of the present invention may be used in any audio system, including phone banking and 




16 


phone information systems, automated teller machines, or any similar audio system that 


= 


17 


requires the generation of audio elements that represent numbers. 


: c~~z 


18 


Turning to FIG. 14, a program flow diagram is shown illustrating the time audio 




19 


generation feature of the present invention. This feature results in a reduced number of 


ri 


20 


audio elements that must be stored in the AEDB 44, The system acts to retrieve the exact 




21 


time when the corresponding audio element is available, but otherwise combines a series 




22 


of time AE's in order to construct an approximate time announcement. 




23 


First, at step 140 the AE's from DB 36 pass through a DJ Filter, which eliminates 




24 


all AE's that are not recorded by an appropriate DJ as indicated in the UPDB 46. The 




25 


current system time 141 is then converted in step 142 into the user's local time zone 




26 


based on information contained in the UPDEM 56 of the UPDB 46. 
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of matches are EXACT HOUR-MINUTE, MINUTE-HOUR, MINUTE-HOUR+1 . In the 




29 


next step at 144, the time is rounded to the highest precision used by the system. The 




30 


Accuracy Prefix is then set to NOW in step 155. An embodiment of the invention has 
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1 


minutes as its highest precision, but other levels of precision could be used (e.g., more 




2 


precise(seconds) or less precise (every 5 minutes)). 




3 


The match type is then used to select a filter that eliminates all AE's that do not 




4 


match the time with the method indicated. At step 146, the AEDB is checked for 




5 


EXACT matches. In order to have an EXACT match, the AE must contain audio that 




6 


completely describes the time (i.e., "quarter after three'"). Similarly, at step 148, the 




7 


system checks for HOUR-MINUTE filter match AE's that describe the hour proceeding a 




8 


minute and a minute following an hour (i.e. '"three'" '"fifteen"'). If no match is found, 




9 


the system in step 151 checks for MINUTE-HOUR filter match AE's that describe the 




10 


minute proceeding an hour and an hour following a minute (i.e., "quarter after" "three 




11 


o'clock"). Finally, in step 154, the MINUTE-HOUR+1 filter matches AE's that describe 


f — = 


12 


the minute proceeding the upcoming hour and the upcoming hour following a minute 




13 


(i.e., 'quarter to' 'four o'clock'). 




14 


If there are AE's (or AE's pairs in the case of audio composition) that pass 


fn 


15 


through the filter, then the ASTF is finished, and the Accuracy Prefix and one of the 


Ln 


16 


selected time AE's (or pair of AE's) are passed to the ASTFQ 92. If no AE's pass 




17 


though the filter, then the time is rounded to the next level of precision at step 144. In an 


j" s 


18 


embodiment, the increments in steps of rounding are 5, 10, 15, 20 and 30 minutes. In an 


~=: 


19 


exemplary embodiment, the rounding precision preferences need not be sorted in order of 




20 


precision. For example, rounding may be done to the nearest 15 minutes before rounding 




21 


to the nearest 10 minutes. After rounding, the actual user time is compared to the rounded 




22 


user time. If the actual user time is less than the rounded time, the Accuracy Prefix is set 




23 


to BEFORE; if it is greater, then the Accuracy Prefix is set to AFTER. Computation then 




24 


resumes at step 146. 




25 


Steps 144-156 are repeated until such time as appropriate audio elements are 




26 


selected. In the unlikely event that still no match is found, then the Time AESF fails. 




27 


This will only happen though in the data-poor case in which there are virtually no time 
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In alternate embodiments, the present method may be used for numbers such as 




30 


stock prices. With stock prices, precision may be considered more important than audio 




31 


quality. In an exemplary embodiment involving stock prices, match types of EXACT, 
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1 DOLLAR-FRACTION, HUNDREDS-TENS-ONES-FRACTION may be used along 

2 with the accuracy prefixes of EXACTLY, UNDER, and OVER. 

3 FIG. 15 illustrates an alternate embodiment of the present invention that includes 

4 a User Customized Audio Element Cache (UAEC) 150. The UAEC includes a memory 

5 data structure and the software necessary to retrieve and store cached audio elements for 

6 a particular user. After each user logs in, the UAEC stores a large percentage of the 

7 audio elements that the user may want to listen to over the course of a predetermined 

8 period of time (e.g., one hour). The cached AE's may include songs, introductions, 

9 outroductions, advertisements, news reports, DJAE's (such as jokes/stories), and other 

10 appropriate AE's. These AE's are determined by the particular user's AESF that is 

1 1 running in the AES 38. The AESF for the particular user selects the AE's to cache based 

12 on the user profile database 46 and user history database 48. 

13 By caching the AE's, the UAEC may reduce the load on the DB by several orders 

14 of magnitude. In an exemplary system, based purely on bandwidth issues, the PRS may 

15 support 100,000 users with approximately 50 audio servers. In this embodiment, each 

16 user consumes 20 kilobits per second (kbps) of bandwidth. A simple Linux server 

17 handles well over 40 megabits per second (Mbps) (disk bandwidth is 400 Mbps and 

18 network bandwidth is up to 100 Mbps). Therefore, each Linux server can easily handle 

19 the bandwidth required for audio streams for approximately 2000 users. Given 2,000 

20 users, there will be 2,000 different audio segments retrieved every 15 seconds (because 

21 the average AE is 15 seconds, and there are potentially 2,000 users per server). As a 

22 result, the PRS must play on average 6700 unique segments per second. No single 

23 database server could handle this many requests. Further, most distributed database 

24 systems could not handle this load. For example, given 1000 servers in the PRS, there 

25 would be approximately 100 users per machine, making approximately 6.7 transactions 

26 per second - approaching the limit of high performance database systems that are 

27 available today. 

28 Using the UAEC, the number of transactions per second required to support the 

29 maximum number of users may be reduced by a factor of two hundred. This dramatic 

30 reduction is achieved by caching (or pre-fetching and storing) approximately one hour's 

31 worth of audio elements when the user logs into the system. Most of what the user will 
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1 want to hear is static audio content (songs, introductions, ads, etc.). Because the user's 

2 preferences and history are known at login and will not change significantly in the course 

3 of an hour (at least not in a typical hour), the UAEC can accurately predict the AE's that 

4 may be required in the future. 

5 In operation, the caching process utilizes the AESF to select not just the next AE 

6 to be played, but the next N AE's that will be played of each type (where N is a large 

7 number determined by the system designer). In an exemplary embodiment, one hour of 

8 AE's is cached, resulting in approximately 240 AE's (each approximately 15 seconds) 

9 being cached for each user. Similar to the operation without a UAEC, each user's AESF 

10 executes queries against DB 36. Each query returns AE's suited to the current user's 

1 1 profile and usage history. 

12 In an alternate embodiment, rather than return a single set of AE's, many different 

13 sets of AE's are returned. For example, AE's corresponding to the best 100 songs that 

14 relate to the user's profile, the 100 most appropriate advertisements, and the 20 most 

15 appropriate sporting team reports, etc. By providing the additional content to the UAEC, 

16 the AES may randomize the selection of content. Further, the additional content permits 

17 the AESF to skip past AE's if the user supplies negative feedback, then obtain additional 

18 content without having to access the FS 34 or DB 44. Instead, the cache is accessed to 

19 retrieve AE's. Accordingly, a PRS using a UAEC 150 generates 2000 transactions per 

20 hour (one per user login) to the FS 34 and DB 36, rather than 2000 transactions every 15 

21 seconds. The cached system generates 0.5 transactions per second (as opposed to the 133 

22 transactions per second that would occur without a cache). This transaction load is quite 

23 feasible with currently available database systems. 

24 Although caching has several benefits, it should be noted that the use of the 

25 UAEC 150 is not always appropriate to cache AE's for an entire hour. For example, 

26 AE's for stock quotes, weather, and traffic may be updated more frequently than every 

27 hour. Accordingly, these types of time critical information are retrieved as needed from 

28 the DB servers. Even so, because the expected number of stock, weather, or traffic 

29 reports per user per hour is relatively low, directly accessing the DB 36 and FS 34 for 

30 these types of audio elements only requires, on average, an additional 0.5 transactions per 

31 second. 
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1 In addition, it is also possible to handle traffic, weather, and stock reports as 

2 special cases in order to permit AE's to be dynamically updated on the FS 34 without any 

3 changes made to either the DB 44 or AES 38. Specifically, the AE identification for the 

4 "current traffic" never changes. The AE file corresponding to the AE identification 

5 number, however, is updated as the conditions change. As a result, the traffic report that 

6 is played to the user is updated as needed with no additional transactions against the DB 

7 and no changes to the AES. 

8 Another aspect of the present invention involves a highly efficient comparison 

9 method within each AESF 42 for selecting audio elements based on a user's profile. An 
10 exemplary audio element that is selected based on the user's profile is an advertising AE. 

□ 11 In operation, the AES selects an advertisement AE for a particular user based on the set 

fP 12 of demographic properties stored in the UPDEM component 56 of each user profile. 

Jij 13 Typical demographic information may include, for example, an indication that the user 

b 14 has the following demographic information: MALE, UNDER-20, LIKES-COMPUTERS, 

n 15 INTERESTED-IN-PURCHASING-COMPUTER, CAR-OWNER, HOMEOWNER, etc. 

test 

1^ 16 It should be understood that this list of demographics is merely intended to be exemplary. 

Jj 17 Any number of demographic information may be stored in the UPDEM 56 without 

cl 18 departing from the scope of the present invention. The AESF then matches an 

G 19 appropriate advertisement based on the user's demographic information. The purpose of 

20 matching an advertisement to a particular user is that the advertiser wishes to pay only for 

21 advertisements shown to a particular sub-group of the PRS audience. Alternatively, the 

22 advertiser may wish to pay more for advertisements played to a particular sub-group of 

23 the PRS audience. For example, an advertiser may wish to match the sex of a particular 

24 user to a particular advertisement (e.g., a golf shop wants to advertise specifically to 

25 men). 

26 In an embodiment, the present invention solves the inefficiencies associated with 

27 using traditional selection methods for choosing an appropriate AE. Specifically, the 

28 present invention contemplates the use of a User Property Comparison Mechanism 

29 (UPCM), which comprises a set of data structures in the UPDB 46 and the AEDB 44, and 

30 a software routine in the AES 38 for efficiently comparing these properties. As 

31 illustrated in Fig. 16a, the illustrated data structures represent the target demographics for 
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1 a particular audio element; and as illustrated in Fig. 16b, the data structures represent the 

2 user demographics. 

3 As shown in FIGS. 16a-c, the UPCM utilizes a trinary property (TRIT) 

4 representation to store and efficiently compare these demographic properties. For most 

5 demographic properties, the information is inherently trinary (i.e., three-valued, rather 

6 than two-valued). For example, a particular user may be female and therefore the value 

7 of the demographic property MALE would be "false." However, if that user were male, 

8 then the demographic property MALE would have the value "true." Finally, it is possible 

9 that for other users in the PRS system that the value of MALE is unknown (i.e., because 

10 they have not chosen to answer that question and that information is unavailable from 

1 1 other sources). Accordingly, the valued store for the MALE demographic property for a 

12 user may potentially take on three values (MALE, NOT-MALE (female), and 

13 UNKNOWN), and is therefore trinary. 

14 Similarly, the demographic properties in an UPDEM 56 of the present invention 

15 are inherently trinary. For example, an advertiser may wish to provide advertisements 

16 only to males. Accordingly, the demographic property MALE would be set to "true" for 

17 a particular advertisement. Another advertiser may not care if the user is MALE. 

18 Accordingly, the property would have to be represented as something other than true or 

19 false. Thus, based on the foregoing, the advertising AE properties are also trinary. 

20 The trinary representation is important because for the each current user, the AES 

21 tests all ads to determine if the user is in that advertisement's demographic target 

22 audience. Each of these advertisements is a candidate for inclusion in the PRS user 

23 customized broadcast. However, given that there are potentially several hundred 

24 properties, storing each property as a separate column in a database table can be very 

25 inefficient, perhaps requiring an entire word of memory per demographic property per 

26 user. One conventional alternative is to pack several properties into a single word of 

27 memory and to then store the word as a single column. Then, in order to match the 

28 properties, the matching program must first extract an entire word from the column and 

29 compare it. These operations are not efficient and are sometimes unavailable within 

30 commercial database packages. 
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1 Accordingly, the TRIT representation is efficient both in storage and retrieval. As 

2 illustrated in Fig. 16a, an exemplary TRIT representation for each property is stored as 1 

3 bit in two separate words. Given that a typical computer word is either 32 or 64 bits, 

4 either 32 or 64 properties can be stored in a pair of words. The 32 (or 64) properties 

5 stored in these two words can be compared in parallel by direct operations on the words. 

6 The properties need never be extracted. In the case of an advertisement, the two 

7 computer words may be known as WANT 162 and TARGET 164. For each user, the two 

8 words may be known as KNOWN 166 and VALUE 168. The nth bit of the WANT and 

9 TARGET words is associated with the nth demographic property (for example, the 4th bit 

10 may be associated with the property MALE). The nth bit of the KNOWN and VALUE 

1 1 words are also associated with the nth demographic property. 

12 In an exemplary embodiment, the representation used in these words is as 

13 follows: if the target demographic for an advertisement is for male users, both the WANT 

14 bit (indicating that the advertisement should be targeted only to listeners who fit into this 

15 demographic) and the TARGET bit (indicating that the advertiser wants to target the 

16 advertisement to users who are male) for the MALE property is set (have the value "1"). 

17 Alternatively, if the target is female users, then WANT=1 and TARGET=0. Finally, if 

18 the target is both men and women, then the particular demographic is not at issue, and 

19 WANT=0 and TARGET is unused and can be either value. 

20 User demographic information is represented similarly. If a user is male, the 

21 KNOWN bit (indicating that the particular demographic "is" "known") is set to 1, and the 

22 VALUE bit (representing whether the particular user falls includes the particular 

23 demographic) is also set to 1. Similarly, if the user is female, then KNOWN=l and 

24 VALUE-0. If the sex of the user is unknown, then KNOWN=0 and VALUE can be 

25 either 1 or 0. Referring only to a single property, a user is in the target audience of the 

26 advertisement if the following Boolean logic statement is true: 

27 (not WANT) or (KNOWN and (TARGET xnor VALUE)) 

28 Accordingly, because this determination can be made using Boolean logic, an 

29 important aspect of the present invention is that the TRIT representation allows the 

30 properties in the WANT, TARGET, KNOWN, and VALUE words to be compared at the 

31 same time using bit- wise binary operations that are both common and very efficient in 



140239-1 





1 




2 








4 








< 
o 




7 




o 
0 




9 




10 




1 1 
1 1 


a— s 




fri; 


1 ^ 










— 


16 




17 




1 o 


D 


10 




90 








21 




22 




















97 

z. / 




28 




29 




30 




31 



computer processors (taking one cycle or less). The bit- wise binary operations result in a 
word 169 containing the results of comparing the 32 (or 64) properties. Thus, if each of 
the bits in the resulting word is 1, then the user is in the target audience of the 
advertisement. 

In addition, most modern-day CISC (complex instruction set computer) systems 
have a native 'xnor 5 (not exclusive-or) operation, on systems that do not, the xnor 
functionality can be replicated by combining other primitive Boolean operations: 

If 'xor' (exclusive-or) is available: 

(not WANT) or (KNOWN and (not (TARGET xor VALUE))) 

otherwise: 

(not WANT) or (KNOWN and ((TARGET and VALUE) or ((not TARGET) and 
(not VALUE))) 

can be used. In all three embodiments, the computation is extremely efficient because the 
operations "not,", "and,", "or,"' "xor," and "'xnor'" are both numerically simple, and 
also fundamental to the operation of modern computing, and have therefore been highly 
optimized. In most situations each operation will take only a single CPU cycle. 

In an alternate embodiment, if the total number of properties is greater than the 
number of bits in a word of memory, then multiple TRIT words may be used. The user is 
in the target audience for the advertisement if all of the TRIT word comparisons match. 

In yet another embodiment of the present invention, the TRIT concept can be 
easily extended to properties that can take on more than 2 values. For example, one such 
property might be the CITY demographic (indicating the city where the user lives), for 
which there may be hundreds of potential values. This demographic could be stored as a 
single 9-bit property (which would allow for a total of 512 possible cities). Then, as 
illustrated in Figure 17a-c, the TRIT representation may be extended so that 9 bits of the 
WANT word 170, the TARGET word 172, the KNOWN word 174, and the VALUE 
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1 word 176 are associated with the CITY demographic property. If the advertiser wishes to 

2 target a particular city, then all 9 of the WANT bits are set 1. The TARGET is set to the 

3 city code (in the illustrated embodiment, the city code for Austin is set as "1001001 10"). 

4 If the user enters the user's city of residence into the PRS system, then all 9 of the 

5 KNOWN bits are set to 1 and the VALUE bits are set to the code corresponding to that 

6 city. And once again, performing the same Boolean algebra, when all the bits in the 

7 result 178 are "l's," then the user has indicated that they live in the city to which the 

8 advertisement is targeted. 

9 In yet another aspect of the present invention, the PRS may include an exclusion 

10 list (XLIST) scheme for insuring a variety of content to a user. According to this aspect 

11 of the invention, the XLIST is used by the AES to insure that two identical, similar, or 

12 closely related AE's are not played in close sequence. The XLIST scheme comprises a 

13 data structure 180 (as illustrated in FIG. 18) in the DB 36 that includes information about 

14 the most recently played AE's, and a software component of the AES that updates and 

15 maintains the XLIST data structure 180. Once created, the XLIST is used by the AES in 

16 the selection of the next AE of a similar type content (e.g., song, news, etc.). 

17 In an embodiment, one exclusion list (XLIST) is created for each type of AE 

18 played by the PRS. In an exemplary embodiment, the XLIST is represented as a ring 

19 buffer in which the AEIDs are maintained for the N most recently played AE's (where N 

20 is selected by the system designer). As is well known in the computer science field, a 

21 ring buffer is a fixed length buffer in which the newest element to be added to the buffer 

22 is added by writing over the oldest element. After an audio element is played by the 

23 PRS, the AES stores the AEID in the XLIST data structure corresponding to that type of 

24 AE. Thus, the XLIST may be used by the AES to insure that two identical, similar, or 

25 closely related AE's are not played in close sequence. 

26 One example of the utility of the XLIST is in the selection of songs. In operation, 

27 the AES selects and caches a number of songs based on the information contained in the 

28 UPMP (music preference) portion of the user profile. In an embodiment, the 100 top 

29 songs that meet the user's criteria are retrieved and stored. If the user's preferences have 

30 not changed since the last log in, the same 100 songs may be retrieved and cached on the 

31 next login. And if the AES selects the songs in order of ranking, the same songs may be 
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1 played every time the user logs in. Even if the selection of an AE is random, there is a 

2 real risk that the same songs may be chosen each time a user logs into the system. In the 

3 case of a song, the information stored includes the song id 182 and the song artist 184. 

4 Using this information the AES can reject songs that are either identical to a recently 

5 played song or have the same artist. 

6 The XLIST may also be created for other types of AE's like news reports or 

7 traffic reports. In the case of a traffic report, the AE's associated with the set of roads 

8 driven by the user are returned to the AES. When constructing a traffic report, it is 

9 important that a particular AE that refers to a particular road, should not be played twice. 

10 In some cases, the user may wish to hear multiple songs by the same artist. In 

11 conventional radio, this practice is called playing a "two-fer." Accordingly, the XLIST 

12 may also be used to insure that pairs of songs from the same artist are played. 

13 FIG. 19 provides a block diagram of an exemplary flow diagram of a system for 

14 using the XLIST of the present invention. Once an audio element is selected, the AEID 

15 is compared to the AEED's in the XLIST corresponding to the type of AE selected (190a- 

16 n). If any of the comparisons results in a determination that the selected audio element is 

17 in the XLIST (represented by the "OR" decision box at 192), then the audio element is 

18 excluded at 194. If the comparison does not establish that the selected audio element is 

19 in the XLIST, then the audio element is accepted at step 196. 

20 While the invention may be adaptable to various modifications and alternative 

21 forms, specific embodiments have been shown by way of example and described herein. 

22 However, it should be understood that the invention is not intended to be limited to the 

23 particular disclosed embodiments. Rather, the invention is to cover all modifications, 

24 equivalents, and alternatives falling within the spirit and scope of the invention as defined 

25 by the claims. Moreover, the different aspects of the disclosed system and methods may 

26 be utilized in various combinations and/or independently. For example, the present 

27 invention is illustrated as providing a customized radio broadcast to one or more users. 

28 However, it should be understood that the concepts and inventions disclosed herein may 

29 be used in the transmission of other types of customized data. Specifically, the concepts 

30 and inventions disclosed herein may be used to provide customized video content to one 

31 or more users based on user profiles. 
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